Systems and methods for implementing second-link routing in packet switched networks

ABSTRACT

A network ( 100 ) includes multiple gateways ( 135, 140 ) and a router ( 105 ) connected to at least one of the multiple gateways ( 135, 140 ). The router ( 105 ) is configured to receive packets that include multiple first virtual circuit identifiers associated with the multiple gateways in the network ( 100 ), assign second virtual circuit identifiers to the at least one connected gateway, and initiate transmission of a message to the at least one connected gateway informing the gateway of the first virtual circuit identifiers.

RELATED APPLICATIONS

This application is a continuation of and claims the benefit of priorityto U.S. patent application Ser. No. 11/530,811, titled “SYSTEMS ANDMETHODS FOR IMPLEMENTING SECOND-LINK ROUTING IN PACKET SWITCHEDNETWORKS,” filed Sep. 11, 2016, the entire contents of which areincorporated by reference herein for all purposes. Application Ser. No.11/530,811 is a continuation of and claims the benefit of priority toU.S. patent application Ser. No. 09/726,056, titled “SYSTEMS AND METHODSFOR IMPLEMENTING SECOND-LINK ROUTING IN PACKET SWITCHED NETWORKS,” filedNov. 30, 2000 (now U.S. Pat. No. 7,106,747, issued Sep. 12, 2006), theentire contents of which are incorporated by reference herein for allpurposes. Application Ser. No. 09/726,056 claims the benefit of priorityto U.S. Provisional Patent Application No. 60/167,918, titled “FASTROUTING SYSTEMS AND METHODS,” filed Nov. 30, 1999, the entire contentsof which are incorporated by reference herein for all purposes.

FIELD OF THE INVENTION

The present invention relates generally to packet switching systems andmethods and, more particularly, to systems and methods for routingInternet Protocol (IP) traffic between local-area networks (LANs)connected via connection-oriented packet switches in mobile ad-hocnetworks using virtual circuits.

BACKGROUND OF THE INVENTION

Connection-oriented protocols have conventionally been used forswitching packets from a source node to a destination node in packetswitching networks. Such protocols have found acceptance in the mobilearena with network hardware installed in trucks and other vehicles orhand-carried. Connections between switches in such environments areoften short-lived as equipment is moved together or apart, and are ofwidely fluctuating throughput quality. The challenge of routing datapackets in this environment is substantially greater than that ofstationary systems. Connection-oriented designs for such systems havebeen favored because of the need to support telephony as well asmachine-to-machine communications. However, IP has become the protocolof choice for end users of such systems, so the need to route IP packetsacross mobile, ad hoc switching networks has been met by adding IProuters on top of the connection-oriented switches, and developingprotocols for establishing the optimal path from one router to another.

The algorithms used by routers to convey connectivity in a mobilenetwork have evolved to keep up with the constantly changing topology,and, as the IP addresses themselves will not convey any topologicalinformation when a router can move about freely, they typically useflooding techniques (sometimes called ‘Shortest Path First’ algorithms)to pass local connectivity information on to more distantly-connectedrouters. A router then uses this information when sending or forwardingpackets to another router to decide which way to send the packet.Typically a router will determine which of its nearest neighbors is‘closest’ to the destination, and then forwards the packet one hop tothe chosen neighbor. To do so when the router is attached to aconnection-oriented switch, as is the case here, the router must selecta virtual circuit on which to place the packet. To facilitate this, itis the current practice for each switch to automatically set up apermanent one-hop circuit to each of its immediate neighbors, with theneighbor forwarding all packets arriving on this circuit to itsconnected IP router.

When workstations on LANs are attached to a network switch, it is thecurrent practice for whatever device is used to bridge between the LANand the switch (technically a gateway) to employ the same technique offorwarding all packets addressed ‘off LAN’ to the same one-hop circuitto be forwarded to the IP-router, where the knowledge of the currentnetwork topology resides.

The use of multi-hop circuits for faster IP packet transport has faced anumber of substantial obstacles: Portable equipment lags the stationaryworld in terms of size and speed, and mobile switch equipment usuallyhas sufficient memory only for small Virtual Circuit (VC) tables. Hence,circuits have to be used selectively. The paths between switches are inconstant flux in a fast moving mobile environment (as, for example, inmilitary or fire-fighting environments), so connections are constantlybeing broken and re-established. IP is not connection-oriented, sosetting up connections as packets arrive for some new destination hasproved infeasible since the standard protocols for negotiating a virtualcircuit across multiple hops take substantially longer than TCP timeoutstolerate. Knowledge of breaks in connectivity is known first to theswitches closest to the break, so packets forwarded by more distantrouters will often arrive with the expectation of a (now-broken) path tothe destination, and the receiving router must be able to acquirecontrol of the packet, rather than have its connected switch forward thepacket further down a no-longer-complete virtual circuit.

For traffic between workstations on different LANs attached by gatewaysto different switches (in trucks, etc.), the problem is even moredifficult since the gateway device bridging between the LAN and arouter/switch has no knowledge of the network topology. Nevertheless,fast communications is a must between workstations in ad hoc networks,and there is a real need for better use of the capabilities of theunderlying connection-oriented switching network for thesecommunications.

Therefore, there exists a need for a system and method that canimplement multi-hop virtual circuit paths in a mobile, ad hoc,connection-oriented packet switching network to support fast andreliable connectivity of connected LANs.

SUMMARY OF THE INVENTION

Systems and methods, consistent with the present invention, address thisand other needs by assigning virtual circuit identifiers (VCIs) to LANgateways and distributing the VCIs to other LAN gateways throughout anetwork. Distribution of these VCIs permits each receiving LAN gatewayto implement virtual circuit paths with other LAN gateways in thenetwork.

In accordance with the purpose of the invention as embodied and broadlydescribed herein, a method of distributing virtual circuit identifiersassociated with gateways in a network includes receiving, at a firstnode, packets comprising a plurality of first virtual circuitidentifiers associated with gateways in the network; determining if anyof the gateways are connected to the first node; assigning secondvirtual circuit identifiers to the connected gateways; and initiatingthe transmission of a message to the connected gateways informing theconnected gateways of the plurality of first virtual circuitidentifiers.

In another implementation consistent with the present invention, amethod of forwarding packets received at a first gateway in a networkincludes receiving a message at the first gateway, the messagecomprising a plurality of virtual circuit identifiers associated withother gateways in the network; receiving packets for transmission fromthe first gateway to a destination address associated with a secondgateway; and sending the received packets towards the second gatewayusing one of the received plurality of virtual circuit identifiers.

BRIEF DESCRIPTION OF THE DRAWINGS

The accompanying drawings, which are incorporated in and constitute apart of this specification, illustrate an embodiment of the inventionand, together with the description, explain the invention. In thedrawings,

FIG. 1 illustrates an exemplary network in which systems and methods,consistent with the present invention, may be implemented;

FIG. 2 illustrates exemplary components of a Router/Switch consistentwith the present invention;

FIG. 3 illustrates exemplary components of a gateway consistent with thepresent invention;

FIG. 4 is an exemplary Switch Virtual Circuit (VC) table for aswitch-gateway interface 250 consistent with the present invention;

FIG. 5 is an exemplary gateway VC table for the switch port consistentwith the present invention;

FIG. 6 is an exemplary gateway forwarding table consistent with thepresent invention;

FIG. 7 is an exemplary router-to-adjacent-router update packetconsistent with the present invention;

FIG. 8 is an exemplary router-to-router gateway-flood-update packetconsistent with the present invention;

FIG. 9 is an exemplary router-to-gateway update packet consistent withthe present invention;

FIG. 10 is a flowchart that illustrates exemplary routergateway-flood-update processing consistent with the present invention;

FIG. 11 is a flowchart that illustrates exemplary gateway processing ofpackets from LAN consistent with the present invention;

FIG. 12 is a flowchart that illustrates exemplary gateway processing ofpackets from switch consistent with the present invention; and

FIG. 13 is a flowchart that illustrates exemplary switch processing ofpackets from gateway consistent with the present invention.

DETAILED DESCRIPTION

The following detailed description of the invention refers to theaccompanying drawings. The same reference numbers in different drawingsidentify the same or similar elements. Also, the following detaileddescription does not limit the invention. Instead, the scope of theinvention is defined by the appended claims.

Systems and methods consistent with the present invention providemechanisms that assign VCIs to LAN gateways and distribute the VCIs toother LAN gateways throughout a network. Distribution of these VCIspermits each receiving LAN gateway to implement virtual circuit pathswith other LAN gateways in the network.

Exemplary Network

FIG. 1 illustrates an exemplary network 100 in which systems andmethods, consistent with the present invention, may be implemented.Network 100 may include multiple routers, each router interconnectedwith another router by conventional links. For purposes of illustration,FIG. 1 shows router/switches R1 105, R2 110, R3 115, R4 120, R5 125 andR6 130 interconnected by links 155. One skilled in the art willrecognize that a typical network may include fewer or greater numbers ofrouters than those shown in FIG. 1.

Network 100 may further include gateways interconnected with one or moreof the routers of the network. For purposes of illustration, FIG. 1shows gateways 135 and 140 connected with routers R1 105 and R6 130,respectively. Each gateway may further connect with a local-area network(LAN). For example, gateways 135 and 140 may connect to LANs 145 and150, respectively. LANs 145 and 150 may include one or more networksusing any type of multi-access media, including, for example, anEthernet or a token ring network. One or more conventional workstations,such as workstations 160 a-160 d, may further interconnect with eachLAN.

Exemplary Router

FIG. 2 illustrates an exemplary router/switch R1 105 that may routepackets in a manner consistent with the present invention.Router/switches 110-130 may be similarly configured. Router/switch R1105 may include an IP-router processor 205, a router memory 210, aswitch memory 215, a switch processor 220, a switch-router interface225, port interfaces 230, 235, 240 and 245, and switch-gateway interface250.

IP-router processor 205 may execute instructions for performing IProuting algorithms and can include a conventional processing device.Switch processor 220 may execute instructions for performing, amongother functions, virtual circuit path switching and can include aconventional processing device. Router memory 210 may provide permanent,semi-permanent, or temporary working storage of data and instructionsfor use by IP-router processor 205. Switch memory 215 may providepermanent, semi-permanent, or temporary working storage of data andinstructions for use by switch processor 220. Router memory 210 andswitch memory 215 may include conventional data storage devices, suchas, for example, Random Access Memory (RAM) or Dynamic RAM (DRAM).

Switch-router interface 225 may include conventional mechanisms forinterfacing IP-router processor 205 with switch processor 220. Port 0interface 230, port 1 interface 235, port 2 interface 240 and port 3interface 245 may each include conventional mechanisms for interfacingrouter 105 with network 100 via links 155. Switch-gateway interface 250may include conventional mechanisms for interfacing router 105 with oneor more gateways, such as gateway 135.

Exemplary Gateway

FIG. 3 illustrates an exemplary gateway 135 that may receive and forwardIP packets to and from LAN 145 consistent with the present invention.Gateway 140 may be similarly configured. Gateway 135 may include aswitch interface 305, a memory 310, a LAN interface 315 and a processor320.

Switch interface 305 may include conventional mechanisms for interfacinggateway 135 with a packet-switch, such as router/switch 105. Memory 310may provide permanent, semi-permanent, or temporary working storage ofdata and instructions for use by processor 320. Memory 310 may includeconventional data storage devices, such as, for example, RAM or DRAM.LAN interface 315 may include conventional mechanisms for interfacinggateway 135 with a LAN, such as LAN 145. Processor 320 may executeinstructions for forwarding packets to and from a connected switch or aconnected LAN in a manner consistent with the present invention.Processor 320 may include a conventional processing device.

Exemplary Router VC Table

FIG. 4 illustrates an exemplary switch Virtual Circuit (VC) table 400,consistent with the present invention, that may be stored in switchmemory 215 for the switch-gateway interface 250 of router/switch 105.Switch VC table 400 may include VC entries 405 containing a switchoutput port (PN_(out)) 410 and an outgoing virtual circuit identifier(VCI_(out)) 415. Switch VC entries 405 may correspond to incoming VCIscontained in received packet headers. A Switch VC entry 405 may includea switch output port (PN_(out)) 410 through which to forward a packet,and it may also include an outgoing virtual circuit identifier(VCI_(out)) 415 that is to be placed in an outgoing packet header inplace of an incoming VCI (VCI_(in)).

Exemplary Gateway VC Table

FIG. 5 illustrates an exemplary gateway VC table 500, consistent withthe present invention, that may be stored in memory 310 of each gatewayin network 100. VC table 500 may include VC entries 505 containing adestination 510. VC destinations 510 may include the gateway processorand the LAN. VC entries 505 may exist for ‘Hello’ protocol messages,‘Route’ protocol messages, and packets intended for the LAN. Forexample, entry one might be designated as the ‘Hello’ protocol entrynumber, entry two might be designated as the ‘Route’ protocol number,and three might be designated as the entry number for all packetsintended for a workstation connected to a gateway LAN, such as LAN 145.

Exemplary Gateway Forwarding Table

FIG. 6 illustrates an exemplary gateway forwarding table 600, consistentwith the present invention, that may be stored in memory 210 of eachrouter in network 100, such as router R1 105, and in memory 310 of eachgateway in network 100. Forwarding table 600 may include destinationgateway entries 605 and outgoing virtual circuit identifier entries(VCI_(out)) 610. Destination gateway entries 605 may include entriesindicating destination gateways in network 100 that the gateway storingforwarding table 600 may be able to reach. VCI_(out) entries 610 mayinclude outgoing virtual circuit identifiers that correspond to eachdestination gateway 605. VCI_(out) entries 610 for different destinationgateways may or may not be distinct, depending on the connected router'sdecision logic and its understanding of the network topology.

Exemplary Router-To-Adjacent Router Update Packet

FIG. 7 illustrates an exemplary packet 700, consistent with the presentinvention, that may be used by a router in network 100, such as routerR1 105, to inform neighboring routers of gateways connected to router RI105. Packet 700 may include a router number 705, a sequence number 710,gateway state data 715, and gateway VCI data 720.

Router number 705 may include a number that identifies the routersending the update packet. Sequence number 710 may provide an indicationof the version of packet 700 sent from the router identified by routernumber 705. For example, older versions of a packet sent from router 105may have lower sequence numbers than newer versions of the tag updatepacket. Gateway state data 715 may include data indicating whethergateways connected to router 105 are operational or non-operational.Gateway VCI data 720 may include data identifying the VCI(s) assigned byrouter 105 to gateways connected to router 105. Gateway VCI data 720 maybe used by another router in the network to fashion a virtual circuitwhose last two links are into some port of the router's switch, and thenout of the switch toward the gateway. To this end, the router may setthe VC Table entry assigned for the gateway to havePn_(out)=SWITCH-GATEWAY INTERFACE 250 and VCI_(out)=IP #, the entrynumber for all packets intended for a workstation connected to thegateway LAN. This allows the other router to form a virtual circuitterminating at this router's gateway for use in fast switching the otherrouter's gateway's packets to this gateway.

Exemplary Router Flood Update Packet

FIG. 8 illustrates an exemplary packet 800, consistent with the presentinvention, that may be used by a router in network 100, such as routerR1 105, to inform other routers in the network of gateways in network100. Packet 600 may include a router number 805, a sequence number 810,gateway identifiers 815, and gateway data 820.

Router number 805 may include a number identifying the router sendingthe packet. Sequence number 810 may provide an indication of the versionof packet 800 sent from the router identified by router number 805. Forexample, older versions of a packet sent from router 105 may have lowersequence numbers than newer versions of the tag update packet. Gatewayidentifiers 815 may identify addresses associated with gateways innetwork 100. Gateway data 820 may indicate up/down state,characteristics, IP address ranges, or any other information that therouters find useful.

Exemplary Router-To-Gateway Update Packet

FIG. 9 illustrates an exemplary packet 900, consistent with the presentinvention, that may be used by a router in network 100, such as routerR1 105, to inform a connected gateway of VCIs assigned to other gatewaysin network 100, so that the gateway may keep its gateway forwardingtable 600 consistent with the router's. Packet 900 may include asequence number 905, gateway identifiers 910, gateway VCIs 915 andadd/drop flags 920.

Sequence number 905 may provide an indication of the version of packet900 sent from the router connected to a gateway. Gateway identifiers 910may include addresses associated with gateways in network 100. Forexample, older versions of a packet sent from router 105 may have lowersequence numbers than newer versions of the update packet. Gateway VCIs915 may include VCIs for each connected gateway to use to reach gatewaysidentified by gateway identifiers 910. Add/drop flag 920 may includestatus indicators that indicate whether gateways identified by gatewayidentifiers 910 should be added to or removed from gateway forwardingtable 600.

Exemplary Router VC Table Update Processing

FIG. 10 is a flowchart that illustrates exemplary processing, consistentwith the present invention, for updating the entries in VC table 400. Asone skilled in the art will appreciate, the method exemplified by FIG.10 can be implemented as a sequence of instructions and stored in switchmemory 215 of router/switches in network 100, such as router/switch 105.

To begin processing, router 105 receives update packets 700 and/or 800from neighboring routers (e.g., R2 110, R3 115) [step 1005]. From thereceived packets, router 105 determines if there are any new gateways innetwork 100 [step 1010]. If so, router 105 assigns and sets VC entry 405in switch's gateway-node VC table 400 for each new gateway connected tonetwork 100 [step 1015] and updates its gateway forwarding table 600. Ifthere are no new gateways in network 100, router 105 determines if anypreviously existing gateways have been disconnected or are down [step1020]. If not, processing proceeds to step 1030. If any previouslyexisting gateways are down, or if their routers have been disconnected,router 105 adjusts the VC entry 405 in VC table 400 for each gatewaydown or disconnected, setting the router output port entry 410 to“IP-router” and setting the VCI_(out) 415 to IP # so that packetsarriving from the gateway with this VCI are sent to the IP Router by itsswitch for processing [step 1025]. Router 105 may then send a packet 900to any connected gateway informing the connected gateway of changes toVCIs that the connected gateways may use to reach other gatewaysconnected to other routers in network 100 [step 1030]. Each connectedgateway, such as gateway 135, updates <Destination Gateway, VCI_(out)>entries 610 in its gateway forwarding table 600 with the Gateway 910 andgateway VCI 915 values received in packet 900 [step 1035] in order tokeep its gateway forwarding table 600 in sync with that of its router.

Exemplary Gateway Packet Forwarding Processing

FIG. 11 is a flowchart that illustrates exemplary processing, consistentwith the present invention, for forwarding packets received at a gatewayin network 100, such as gateway 135, from a connected router/switch,such as router/switch 105. As one skilled in the art will appreciate,the method exemplified by FIG. 11 can be implemented as a sequence ofinstructions and stored in memory 310 of gateways 135.

To begin processing, gateway 135 may receive a packet from router/switch105 [step 1105]. Gateway 135 may then read the incoming VCI (VCI_(IN))from the packet header [step 1110]. Gateway 135 may determine ifVCI_(IN) is equal to the ‘Hello’ protocol entry number [step 1115]. Ifso, gateway 135 processes the received packet in the conventionalfashion for ‘hello’ or ‘keep-alive’ protocols (which are used todetermine the up/down state of an attached device)[step 1120]. If not,gateway 135 may determine if VCI/_(IN) is equal to the ‘route number’[step 1125]. If so, gateway 135 processes the receivedrouter-to-gateway-update packet 900 and updates its gateway forwardingtable 600 from data in packet 900 [step 1130]. If not, gateway 135 maydetermine if VCI_(IN) is equal to the IP number [step 1135]. If so,gateway 135 removes the switch-packet header containing the VCI_(IN)from the packet [step 1140] and forwards the packet to LAN 145 [step1145]. If VCI_(IN) is not equal to any of these numbers (typically 1,2,and 3 respectively), then gateway 135 may discard the packet as being ofan unknown type [step 1150].

FIG. 12 is a flowchart that illustrates exemplary processing, consistentwith the present invention, for forwarding packets received at a gatewayin network 100, such as gateway 135, from a workstation connected to aLAN, such as LAN 145. As one skilled in the art will appreciate, themethod exemplified by FIG. 12 can be implemented as a sequence ofinstructions and stored in memory 310 of gateway 135.

To begin processing, gateway 135 may receive a packet sent from aworkstation, such as workstation 160 a, across LAN 145, the packetcontaining a destination IP address that resides outside of LAN 145[step 1205]. Gateway 135 may determine if the destination IP address isassociated with a gateway in its gateway forwarding table 600 [step1210]. If not, gateway 135 can insert the customary default IP # VCI[typically the number “1”] in the packet header [step 1225] so that theswitch, on receiving the packet, will forward it to its router forcustomary processing. If gateway 135 determines that the destination IPaddress is associated with a gateway in its gateway forwarding table600, gateway 135 can retrieve a VCI_(out) 610, associated with thegateway, from the gateway VCI table 600 [step 1215]. Gateway 135 maythen insert VCI_(out) 610 in the packet header [step 1220].

At step 1230, gateway 135 can forward the received packet to switch 105.

Exemplary Router Forwarding Processing

FIG. 13 is a flowchart that illustrates exemplary processing, consistentwith the present invention, for forwarding packets received at a switchin network 100, such as switch 105, from a gateway, such as gateway 135,connected to its a switch-gateway interface 250. As one skilled in theart will appreciate, the method exemplified by FIG. 13 can beimplemented as a sequence of instructions and stored in switch memory215 of router R1 105.

To begin processing, router/switch R1 105 may receive a packet fromswitch-gateway interface 250 [step 1305] and then may inspect thepacket's incoming VCI (VCI_(in)) in the packet header [step 1310].Router R1 105 may further determine an output port number (PN_(out)) 410from VC entry 405, corresponding to VCI_(in), of switch-gatewayinterface 250 VC table 400 [step 1315]. Router R1 105 may then determinean outgoing VCI (VCI_(out)) 415 from VC entry 405, corresponding toVCI_(in), of VC table 400 [step 1320]. Router R1 105 can replaceVCI_(in) in the packet header with the determined VCI_(out) 415 [step1325]. Router RI 105 may then forward the packet to PN_(out) 410 (eitheran output port or IP-router 205 [step 1330].

Conclusion

Systems and methods consistent with the present invention providemechanisms that assign virtual circuit identifiers to LAN gateways anddistribute the VCIs to other LAN gateways throughout a network.Distribution of these VCIs permits each receiving LAN gateway toimplement virtual circuit paths with other LAN gateways in the network.

The foregoing description of exemplary embodiments of the presentinvention provides illustration and description, but is not intended tobe exhaustive or to limit the invention to the precise form disclosed.Modifications and variations are possible in light of the aboveteachings or may be acquired from practice of the invention. Forexample, while certain components of the invention have been describedas implemented in hardware and others in software, other configurationsmay be possible. Also, while series of steps have been described withregard to FIGS. 10-13, the order of the steps may be altered in otherimplementations consistent with the present invention. No element, step,or instruction used in the description of the present application shouldbe construed as critical or essential to the invention unless explicitlydescribed as such. The scope of the invention is defined by thefollowing claims and their equivalents.

What is claimed is:
 1. A packet-based network comprising: a firstgateway node communicatively coupled between a first routing node and afirst local area network (LAN); a second gateway node communicativelycoupled between a second routing node and a second LAN; and at least onevirtual circuit established between the first gateway node and thesecond gateway node operable to communicate Internet Protocol (IP)traffic between the first LAN and the second LAN, wherein the virtualcircuit is identified in memory of the first gateway node usinginformation received from the first routing node, the informationcomprising a virtual circuit identifier associated with the secondgateway node, wherein the at least one virtual circuit is identified inmemory of the second gateway node using information received from thesecond routing node, the information comprising a virtual circuitidentifier associated with the first gateway node, wherein each of thefirst and second routing nodes and the first and second gateway nodeseach include a gateway forwarding table for storing the virtual circuitidentifiers associated with each of the gateway nodes.
 2. The network asrecited in claim 1, wherein the first routing node and the secondrouting node are operable to transmit one or more messages therebetween,the message to ultimately inform their respective connected gatewaynodes of the virtual circuit identifiers associated with the othergateway node.
 3. The network as recited in claim 1, wherein the firstrouting node updates at least one virtual circuit table stored at thefirst routing node using both of the virtual circuit identifierassociated with the first gateway node and the virtual circuitidentifier associated with the second gateway node.
 4. The network asrecited in claim 1, wherein the second routing node updates at least onevirtual circuit table stored at the second routing node using both ofthe virtual circuit identifier associated with the first gateway nodeand the virtual circuit identifier associated with the second gatewaynode.
 5. A method comprising: receiving a packet at a node; inspecting aheader of the packet for an input virtual channel identifier (VCI_(in));determining an output port number (PN_(out)) by referencing a virtualchannel table stored on the node with the VCI_(in), the PN_(out)referencing a port on the node; determining an output virtual channelidentifier (VCI_(out)) by referencing the virtual channel table with theVCI_(in); replacing the VCI_(in) in the header of the packet with thedetermined VCI_(out); forwarding the packet to at least one of anothernode utilizing the VCI_(out) and sent via the determined PN_(out); andupdating the virtual channel table at the node with one or more changesto the virtual channels associated with the one or more gateways;wherein the virtual channel table includes a list of VCI_(out)identifiers that reference one or more virtual channels associated withone or more gateways communicably connected to the node, and wherein theone or more gateways each include at least one virtual channel table forstoring virtual channel entries associated with virtual channelsutilized for incoming packets from one or more routers.
 6. The method asrecited in claim 5, wherein the node and the at least one of anothernode each comprise at least one of a router, switch, or gateway.
 7. Themethod as recited in claim 5, further comprising the node initiatingtransmission of a packet to one or more neighboring routers, the packetinforming the neighboring routers of the virtual channels associatedwith the one or more gateways.
 8. The method as recited in claim 5,wherein the one or more gateways each include at least one gatewayforwarding table to store virtual channel identifiers associated withthe one or more other gateways.
 9. The method as recited in claim 5,wherein the node includes at least one gateway forwarding table to storevirtual channel identifiers associated with each of the one or moregateways.
 10. A node comprising: a virtual channel table to store one ormore input virtual channel identifier (VCI_(in)) entries, one or morerouter output port (PN_(out)) entries, and one or more output virtualchannel identifier (VCI_(out)) entries, wherein the one or moreVCI_(out) entries reference one or more virtual channels associated withone or more gateways communicably connected to the node; and a networkinterface operable to: receive a packet; inspect a header of the packetfor a VCI_(in) entry; determine a PN_(out) entry by referencing thevirtual channel table with the VCI_(in); determine a VCI_(out) entry byreferencing the virtual channel table with the VCI_(in); replace theVCI_(in) in the header of the packet with the determined VCI_(out); andforward the packet to at least one of another node utilizing theVCI_(out) and sent via the determined PN_(out), wherein the one or moregateways each include at least one gateway forwarding table to storevirtual channel identifiers associated with the one or more othergateways, and wherein the one or more gateways each include at least onevirtual channel table for storing virtual channel entries associatedwith virtual channels utilized for incoming packets from one or morerouter/switches.
 13. The node as recited in claim 12, wherein the nodeand the at least one of another node each comprise at least one of arouter, switch, or gateway.
 14. The node as recited in claim 12, whereinthe network interface is further operable to initiate transmission of apacket to one or more neighboring router/switches, the packet informingthe neighboring router/switches of the virtual channels associated withthe one or more gateways.